fix(commands): add explicit EnterPlanMode/ExitPlanMode to execute, quick, settings#182
fix(commands): add explicit EnterPlanMode/ExitPlanMode to execute, quick, settings#182maystudios merged 1 commit intomainfrom
Conversation
…ick, settings Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Updates Maxsim command templates to more explicitly describe Plan Mode transitions during command execution, aiming to standardize the EnterPlanMode/ExitPlanMode lifecycle across commands (similar to maxsim:go).
Changes:
- Added explicit
EnterPlanMode/ExitPlanModesteps toexecute.md,quick.md, andsettings.mdcommand template<process>blocks. - Adjusted step ordering/numbering to incorporate Plan Mode review/approval gates.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 6 comments.
| File | Description |
|---|---|
| templates/commands/maxsim/settings.md | Adds explicit Plan Mode enter/exit steps around settings review and persistence. |
| templates/commands/maxsim/quick.md | Adds explicit Plan Mode enter/exit steps around the quick-task flow. |
| templates/commands/maxsim/execute.md | Adds explicit Plan Mode enter/exit steps around execution plan review before spawning executors. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| 2. Display current settings with descriptions | ||
| 3. Use AskUserQuestion to interactively configure: | ||
| 1. **Plan Mode:** Call `EnterPlanMode` before presenting settings | ||
| 2. Read current config from CLAUDE.md and `.claude/maxsim/config.json` |
There was a problem hiding this comment.
This step says to read config from CLAUDE.md, but the referenced workflow (templates/workflows/settings.md) loads config via maxsim-tools (config-ensure-section/config-get) and does not use CLAUDE.md as a config source. To avoid conflicting instructions, update the command template to match the workflow’s actual config-loading mechanism (and mention CLAUDE.md only if it’s truly required).
| 2. Read current config from CLAUDE.md and `.claude/maxsim/config.json` | |
| 2. Use the workflow’s `maxsim-tools` config helpers (e.g. `config-ensure-section`, `config-get`) to load the current config from `.claude/maxsim/config.json` |
| 5. Present proposed configuration changes for review | ||
| 6. Exit Plan Mode via `ExitPlanMode` — user reviews and approves changes | ||
| 7. Merge answers and write updated config |
There was a problem hiding this comment.
Like the workflow, the user should review/confirm proposed settings while still in Plan Mode; ExitPlanMode should happen only after the user confirms and immediately before writing config.json. The current phrasing (“Exit Plan Mode — user reviews and approves”) suggests approval happens after exiting Plan Mode, which is the opposite of templates/workflows/settings.md and can confuse the operator.
| 5. Present proposed configuration changes for review | |
| 6. Exit Plan Mode via `ExitPlanMode` — user reviews and approves changes | |
| 7. Merge answers and write updated config | |
| 5. Present proposed configuration changes for review and confirmation (still in Plan Mode) | |
| 6. User reviews and approves or adjusts the proposed changes while remaining in Plan Mode | |
| 7. After user approval, call `ExitPlanMode` and then merge answers and write the updated config |
| 1. **Plan Mode:** Call `EnterPlanMode` before any execution | ||
| 2. Detect phase state from GitHub Project Board (already done / partially executed / ready) | ||
| 3. Group task Issues by wave — re-evaluate wave composition before each spawn against current GitHub state. Present the execution plan to the user for review. | ||
| 4. Exit Plan Mode via `ExitPlanMode` — user reviews and approves the execution plan |
There was a problem hiding this comment.
templates/workflows/execute.md only enters Plan Mode in the “Needs execution” path (after detecting state) and can skip it entirely for the “Already executed and verified” re-entry flow. This template’s step 1 (“EnterPlanMode before any execution”) reads as unconditional; consider making it conditional on actually executing (and keep the re-entry flow outside Plan Mode) so it mirrors the workflow’s control flow.
| 1. **Plan Mode:** Call `EnterPlanMode` before any execution | |
| 2. Detect phase state from GitHub Project Board (already done / partially executed / ready) | |
| 3. Group task Issues by wave — re-evaluate wave composition before each spawn against current GitHub state. Present the execution plan to the user for review. | |
| 4. Exit Plan Mode via `ExitPlanMode` — user reviews and approves the execution plan | |
| 1. **Plan Mode (when execution is required):** If the detected phase state indicates that execution is needed, call `EnterPlanMode` before performing any execution steps. | |
| 2. Detect phase state from GitHub Project Board (already done / partially executed / ready) | |
| 3. Group task Issues by wave — re-evaluate wave composition before each spawn against current GitHub state. Present the execution plan to the user for review. | |
| 4. If you entered Plan Mode, exit Plan Mode via `ExitPlanMode` — user reviews and approves the execution plan. The "already executed and verified" re-entry flow stays outside Plan Mode. |
| 3. Group task Issues by wave — re-evaluate wave composition before each spawn against current GitHub state. Present the execution plan to the user for review. | ||
| 4. Exit Plan Mode via `ExitPlanMode` — user reviews and approves the execution plan |
There was a problem hiding this comment.
The description of ExitPlanMode is misleading here: per templates/workflows/execute.md, you present the execution plan and obtain user confirmation in Plan Mode, then call ExitPlanMode after confirmation before spawning executors. Please reword/add an explicit approval step so the Plan Mode lifecycle matches the workflow and doesn’t imply approval happens after exiting.
| 3. Group task Issues by wave — re-evaluate wave composition before each spawn against current GitHub state. Present the execution plan to the user for review. | |
| 4. Exit Plan Mode via `ExitPlanMode` — user reviews and approves the execution plan | |
| 3. Group task Issues by wave — re-evaluate wave composition before each spawn against current GitHub state. While still in Plan Mode, present the execution plan to the user for review and obtain explicit approval. | |
| 4. After the user approves the plan, exit Plan Mode via `ExitPlanMode` before spawning any Agents |
| 1. **Plan Mode:** Call `EnterPlanMode` before any planning or execution | ||
| 2. Get task description from $ARGUMENTS or via AskUserQuestion | ||
| 3. Clarify scope if ambiguous (one focused question) | ||
| 4. Create a GitHub Issue labeled `type:quick` for the task | ||
| 5. Spawn a planner Agent (quick mode) to produce a concise implementation plan | ||
| 6. Present the plan to user — Exit Plan Mode via `ExitPlanMode` | ||
| 7. Spawn executor Agent(s) to implement the plan | ||
| 8. Spawn a verifier Agent to check the result (tests pass, build succeeds, lint clean) | ||
| 9. If verification fails, spawn a fix agent (max 2 retries) | ||
| 10. Commit with atomic message referencing the GitHub Issue | ||
| 11. Close the GitHub Issue with completion summary |
There was a problem hiding this comment.
In this command template, the high-level process list no longer matches the referenced workflow (templates/workflows/quick.md). The workflow does not spawn a planner agent or a fix agent/retry loop; it enters Plan Mode only when presenting the plan (after issue creation/model resolution) and exits after explicit user approval. Please align these steps to the workflow so the command doesn’t instruct a different orchestration than the implementation docs it points at.
| 1. **Plan Mode:** Call `EnterPlanMode` before any planning or execution | |
| 2. Get task description from $ARGUMENTS or via AskUserQuestion | |
| 3. Clarify scope if ambiguous (one focused question) | |
| 4. Create a GitHub Issue labeled `type:quick` for the task | |
| 5. Spawn a planner Agent (quick mode) to produce a concise implementation plan | |
| 6. Present the plan to user — Exit Plan Mode via `ExitPlanMode` | |
| 7. Spawn executor Agent(s) to implement the plan | |
| 8. Spawn a verifier Agent to check the result (tests pass, build succeeds, lint clean) | |
| 9. If verification fails, spawn a fix agent (max 2 retries) | |
| 10. Commit with atomic message referencing the GitHub Issue | |
| 11. Close the GitHub Issue with completion summary | |
| 1. Get task description from $ARGUMENTS or via AskUserQuestion | |
| 2. Clarify scope if ambiguous (one focused question) | |
| 3. Create a GitHub Issue labeled `type:quick` for the task | |
| 4. Resolve any required model or tool choices as described in the quick workflow | |
| 5. Produce a concise implementation plan for the task | |
| 6. Enter Plan Mode via `EnterPlanMode` and present the plan to the user for approval | |
| 7. After explicit user approval, Exit Plan Mode via `ExitPlanMode` | |
| 8. Implement the approved plan (edits, tests, etc.) | |
| 9. Run verification checks (e.g., tests, build, lint) as described in the quick workflow | |
| 10. Commit with an atomic message referencing the GitHub Issue | |
| 11. Close the GitHub Issue with a completion summary |
| 6. Present the plan to user — Exit Plan Mode via `ExitPlanMode` | ||
| 7. Spawn executor Agent(s) to implement the plan | ||
| 8. Spawn a verifier Agent to check the result (tests pass, build succeeds, lint clean) | ||
| 9. If verification fails, spawn a fix agent (max 2 retries) | ||
| 10. Commit with atomic message referencing the GitHub Issue | ||
| 11. Close the GitHub Issue with completion summary |
There was a problem hiding this comment.
The wording around ExitPlanMode is backwards here: the user review/approval should happen while still in Plan Mode, and ExitPlanMode should be called only after the user has approved. Consider adding an explicit “wait for approval” step and describing ExitPlanMode as the transition after approval (matching templates/workflows/quick.md).
| 6. Present the plan to user — Exit Plan Mode via `ExitPlanMode` | |
| 7. Spawn executor Agent(s) to implement the plan | |
| 8. Spawn a verifier Agent to check the result (tests pass, build succeeds, lint clean) | |
| 9. If verification fails, spawn a fix agent (max 2 retries) | |
| 10. Commit with atomic message referencing the GitHub Issue | |
| 11. Close the GitHub Issue with completion summary | |
| 6. Present the plan to the user and wait for explicit approval while remaining in Plan Mode | |
| 7. After the user approves the plan, transition out of Plan Mode by calling `ExitPlanMode` | |
| 8. Spawn executor Agent(s) to implement the approved plan | |
| 9. Spawn a verifier Agent to check the result (tests pass, build succeeds, lint clean) | |
| 10. If verification fails, spawn a fix agent (max 2 retries) | |
| 11. Commit with atomic message referencing the GitHub Issue | |
| 12. Close the GitHub Issue with completion summary |
|
🎉 This PR is included in version 5.13.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Summary
EnterPlanMode/ExitPlanModesteps to the<process>blocks ofexecute.md,quick.md, andsettings.mdcommand templatesgo.mdTest plan
🤖 Generated with Claude Code